Effective collaboration in healthcare systems

ABSTRACT

According to an aspect of the present disclosure, a healthcare system receives a request to initiate a chat in relation to a patient, identifies healthcare providers having responsibility for the patient, and provides a chat session with the identified healthcare providers as participants. Upon receiving a command (requesting information on the patient) during the chat session, the healthcare system retrieves an electronic medical record (EMR) of the patient and sends the EMR to the participants of the chat session. In one embodiment, the command does not specify the identifier of the patient in the chat session. In another embodiment, when an external EMR system maintains EMRs of the patient, the healthcare system retrieves the EMR of the patient from the EMR system without requiring the participant to manually authenticate after specifying the command. Accordingly, the healthcare system is configured to facilitate collaboration among healthcare providers.

CROSS-REFERENCE TO RELATED APPLICATIONS

This Application is a Continuation of U.S. patent application Ser. No.16/753,093 filed on Oct. 3, 2018, which claims the benefit of priorityof U.S. Provisional Application No. 62/567,359, filed Oct. 3, 2017, thecontent of which is incorporated herein by reference in its entirety.

TECHNICAL FIELD

Embodiments of the present disclosure relate generally to healthcaresystems and in particular to providing effective collaboration in suchsystems.

BACKGROUND

Healthcare systems aid the delivery of various healthcare aspects suchas work-flow coordination, records management, diagnosis, etc., as iswell known in the relevant arts. Healthcare systems are often employedby hospitals (healthcare delivery parties, in general) to aid variousparties such as the medical staff and patients.

Collaboration refers to the process of facilitating multipleparticipants (e.g. healthcare personnel such as doctors, nurses, careteam, etc.), who may be located in different geographical locations, tocommunicate among themselves by way of instant messaging, electronicmailing, file sharing, remote screen sharing, etc.

Aspects of the present disclosure are directed to providing effectivecollaboration in healthcare systems.

BRIEF SUMMARY

According to an aspect of the present disclosure, a healthcare systemreceives a request to initiate a chat in relation to a patient,identifies healthcare providers having responsibility for the patient,and provides a chat session with the identified healthcare providers andcare team as participants. Upon receiving a command (requestinginformation on the patient) as a text of the chat session, thehealthcare system retrieves an electronic medical record (EMR) of thepatient and sends the EMR to the participants of the chat session.Accordingly, the healthcare system is configured to facilitatecollaboration among healthcare providers.

In one embodiment, the command does not specify the identifier of thepatient in the chat session. In another embodiment, when an external EMRsystem maintains EMRs of the patient and the command is received from afirst participant, the healthcare system retrieves the EMR of thepatient from the EMR system without requiring the first participant tomanually authenticate after specifying the command.

According to one more aspect of the present disclosure, the healthcaresystem includes the EMR of the patient in the text of the chat session,thereby enabling the EMR of the patient to be stored as part of the textof the chat session in a non-volatile storage.

According to yet another aspect of the present disclosure, in responseto receiving an indication to save the chat session, the healthcaresystem enables the participants of the chat session to edit the text ofthe chat session to form an edited text and stores the edited text in anon-volatile storage.

According to an aspect of the present disclosure, a healthcare providerusing a client system sends a request to initiate a chat in relation toa patient and participates in a chat session with healthcare providersas participants, the healthcare providers having responsibility for thepatient. The healthcare provider, using the client system, sends acommand as a text of the chat session, with the command requestinginformation on the patient. In response to the command, an electronicmedical record (EMR) of the patient is sent to the participants of thechat session. Accordingly, client system is configured to facilitatecollaboration among healthcare providers.

In one embodiment, the healthcare provider (using the client system)does not specify the identifier of the patient as part of the command.In another embodiment, the healthcare provider shares the EMR of thepatient without authentication after specifying the command.

According to one more aspect of the present disclosure, the clientsystem displays the EMR of the patient in the text of the chat session,such that all the participants of the chat session are able to view theEMR details of the patient, thereby enabling the EMR of the patient tobe stored as part of the text of the chat session in a non-volatilestorage. In one embodiment, the information is displayed only for apre-configured time period (e.g. 10 seconds) in the chat session.

According to yet another aspect of the present disclosure, uponreceiving an indication to save the chat session, the client systemenables the healthcare provider to edit the text of the chat session toform an edited text and to send the edited text for storing in anon-volatile storage.

According to an aspect of the present disclosure, a third-party digitalprocessing system (external to the healthcare system) receives a requestfor healthcare providers associated with a patient to initiate a chat inrelation to the patient, identifies healthcare providers havingresponsibility for the patient, and sends the identified healthcareproviders as being associated with the patient to facilitate a chatsession to be provided with the healthcare providers as participants.Upon receiving another request requesting information on the patient inresponse to a command as a text of the chat session, the third-partysystem retrieves an electronic medical record (EMR) of the patient andsends the EMR in response to receiving of another request to facilitatethe EMR to be provided to the participants of the chat session.Accordingly, the third-party (external) digital processing system isconfigured to facilitate collaboration among healthcare providers.

In one embodiment, the command is received from a first participant anddoes not specify the identifier of the patient in the chat session. Inanother embodiment, the EMR of the patient is retrieved withoutrequiring the first participant to manually authenticate afterspecifying the command.

According to another aspect of the present disclosure, the EMR of thepatient is included in the text of the chat session, such that all theparticipants of the chat session are able to view the patient contextinformation thereby enabling the EMR of the patient to be stored as partof the text of the chat session in a non-volatile storage. In oneembodiment, the information is displayed only for a pre-configured timeperiod (e.g. 10 seconds) in the chat session.

According to yet another aspect of the present disclosure, the externalsystem is an insurance server belonging to an insurance carrier, theinsurance server maintaining information on patients having insurancecoverage with the insurance carrier. According to one more aspect of thepresent disclosure, the external system is an enterprise serverbelonging to a third-party enterprise.

Several aspects of the invention are described below with reference toexamples for illustration. However, one skilled in the relevant art willrecognize that the disclosure can be practiced without one or more ofthe specific details or with other methods, components, materials and soforth. In other instances, well-known structures, materials, oroperations are not shown in detail to avoid obscuring the features ofthe disclosure. Furthermore, the features/aspects described can bepracticed in various combinations, though only some of the combinationsare described herein for conciseness.

While the features of the present disclosure are described substantiallyin the context of healthcare services, it should be appreciated thatseveral aspects of the present disclosure can be applied to otherindustries such as banking, telecommunication, transport, education,utilities and retail services.

BRIEF DESCRIPTION OF THE DRAWINGS

Example embodiments of the present disclosure will be described withreference to the accompanying drawings briefly described below.

FIGS. 1A-1C depicts example environments in which several aspects ofproviding effective collaboration in healthcare systems can beimplemented.

FIG. 2 is a block diagram of an example computing system in whichseveral aspects of providing effective collaboration in healthcaresystems can be implemented.

FIG. 3 is a flowchart illustrating the manner in which effectivecollaboration is provided in a healthcare system according to an aspectof the present disclosure.

FIG. 4 illustrates an example graphical user interface (GUI) of achat/collaboration session among multiple healthcare providers in anembodiment.

FIG. 5 depicts portions of a visit summary data specifying the detailsof interactions between patients and healthcare providers in oneembodiment.

FIG. 6 is a block diagram illustrating an example implementation of ahealthcare system.

FIG. 7 is a sequence diagram illustrating the manner in which effectivecollaboration with context awareness is provided by a healthcare systemin one embodiment.

FIG. 8 is a block diagram illustrating the manner in which a healthcaresystem is provided using a cloud infrastructure in an embodiment.

FIG. 9 is a block diagram illustrating the details of digital processingsystem 900 in which various aspects of the present disclosure areoperative by execution of appropriate executable modules.

In the drawings, like reference numbers generally indicate identical,functionally similar, and/or structurally similar elements. The drawingin which an element first appears is indicated by the leftmost digit(s)in the corresponding reference number.

DETAILED DESCRIPTION OF THE EMBODIMENTS OF THE DISCLOSURE 1. ExampleEnvironments

FIGS. 1A-1C depicts example environments in which several aspects ofproviding effective collaboration in healthcare systems can beimplemented. The example environments are shown containingentities/elements such as patient 110, healthcare provider 120,insurance carrier 130, enterprise 140 and healthcare system 150. Theelements are shown interconnected by data links 115, 125, 135, 145, etc.

Merely for illustration, only representative number/type ofelements/links is shown in the Figure. Many environments often containmany more elements and/or links, both in number and type, depending onthe purpose for which the environment is designed. Each element and datalink of FIGS. 1A-1C is described below in further detail.

Patient 110 refers to a recipient of healthcare services. Information onpatient 110 is commonly maintained in the form of electronicmedical/health records (EMR/EHRs), as is well known in the relevantarts. EMR/EHRs (hereinafter referred commonly as EMRs) may specifydetails such as patient identity, dates of visit to avail healthcareservices, symptoms of health problems faced by the patient, lab reports,etc.

Healthcare provider 120 refers to a physician/doctor, nurse, medicalstaff, care giver, etc. who provide one or more healthcare services tothe patient. Healthcare providers are commonly associated with ahealthcare organization (hospital, clinic, etc.) located at one or moregeographical locations. Each healthcare provider commonly hasresponsibility for one or more patients.

Insurance carrier 130 represents an organization that offers varioushealth insurance plans to patients, with each insurance plan beingdesigned to protect the patient financially when health problems arise.In the below description, it is assumed that patient 110 has subscribedto at least one insurance plan offered by insurance carrier 130.

Enterprise 140 represents a third party organization that is related toproviding healthcare or management services (e.g. customer relationshipmanagement). Enterprise 140 generally operates data and applicationsindependent of the other elements noted here.

Healthcare system 150 represents a system that assists a healthcareorganization in the delivery of healthcare services to patients.Healthcare system 150 aids in various healthcare aspects such aswork-flow coordination between healthcare providers and patients,records (such as EMR) management, diagnosis, etc., as is well known inthe relevant arts.

Referring to FIG. 1A, healthcare system 150 receives a request toinitiate a chat in relation to a patient. In one embodiment, the requestis received from healthcare provider 120 (via data link 125) such as aphysician/doctor. The chat request may be received when the physicianwants to review the status of his/her patients or in response to patient110 coming for check-up/review with the physician, either in-house or asan out-patient at a premises of the healthcare organization as is wellknown.

In alternative embodiments, the chat request may be received frompatient 110 via data link 115, for example, when the patient wishes todiscuss health related issues such as symptoms, diagnosis, medicines,etc. with any healthcare providers of the healthcare organization. Thechat request may also be received from insurance carrier 130 via datalink 135 or from enterprise 140 via data link 145, for example, when theinsurance carrier/enterprise wishes to review the condition of aspecific patient with the healthcare providers related to the patient.

Healthcare system 150 identifies healthcare providers havingresponsibility for patient 110. The identification may be performed in aknown way, for example, by examining a visit summary data specifying thehealthcare providers that had interacted with patient 110 during theprevious visits. Healthcare system 150 may also identify additionalpersonnel belonging to insurance carrier 130 or enterprise 140 who haveresponsibility for patient 110. Such identification may be performed byhealthcare system 150 sending corresponding requests via data links 135and 145 and receiving respective responses from insurance carrier 130and enterprise 140 indicating the specific personnel related to thepatient.

Healthcare system 150 provides a chat/collaboration session with theidentified healthcare providers (and additional personnel) asparticipants of the chat session. After the chat session is initiated,each participant of the chat session is facilitated to send and receive(via data links 115, 125, 135 and 145) messages with the otherparticipants in the chat session. The chat session facilitates thephysician to discuss on the condition/medication of patient 110 withother healthcare providers/additional personnel.

In one embodiment, each of the identified providers/personnel (user) issent an invitation (via data links 115, 125, 135 and 145) to join thechat session created in relation to the patient. Upon the invited usersindicating acceptance of the invite, the accepting users are added asparticipants to the chat session.

Healthcare system 150 receives a command as a text of the chat session,the command requesting information on the patient. The command may bespecified in any convenient manner, for example, as a string formingpart of text, by selection of a suitable user interface element, etc.The command may be received from patient 110 (via data link 115),healthcare provider 120 (via data link 125), personnel of insurancecarrier 130 (via data link 135) or personnel of enterprise 140 (via datalink 145).

Healthcare system 150 retrieves an EMR of the patient in response toreceipt of the command. The EMR may be retrieved from an internal datastore forming part of healthcare system 150. In one embodiment,healthcare system 150 sends a request for patient information via datalink 145 to enterprise 140 and receives the EMR of the patient as aresponse to the request from enterprise 140 via data link 145. Accordingto an aspect of the present disclosure, the participants of the chatsession are facilitated to access the data/files on enterprise 140without requiring the participants to sign into enterprise 140. MultipleEMRs from the different data stores may also be retrieved, withhealthcare system 150 then forming a consolidated EMR of the patientfrom the retrieved data.

Healthcare system 150 then provides the EMR of the patient to theparticipants of the chat session as a response to the command. Forexample, healthcare system 150 may send the EMR of the patient in aformat ready for display on systems used by patient 110 and/orhealthcare provider 120. Each system then presents/displays the patientcontext information (EMR) as part of the chat session, such that all theparticipants of the chat session are able to view the patient contextinformation. In one embodiment, the information is displayed only for apre-configured time period (e.g. 10 seconds).

According to an aspect of the present disclosure, the patient contextinformation is provided in the form of one or more messages of the chatsession (similar to the other message manually sent by the participantsvia data links 115, 125, 135 and 145). By providing as messages, thepatient context messages are facilitated to be saved/stored as part ofchat history.

According to another aspect of the present disclosure, healthcare system150 receives an indication to save/persist the chat session. Theindication may be received from any one of the participants of the chatsession via any one of data links 115, 125, 135 and 145. Saving the chatsession implies that the text of the chat session including themessages/files exchanged between the participants, the patient contextinformation retrieved and displayed as part of the text of the chatsession, etc. be stored in a non-volatile storage (e.g. a data storeforming part of healthcare system 150).

Healthcare system 150, in response to receiving the indication, enablesthe participants to edit the text of the chat session to form an editedtext. In one embodiment, the list of messages exchanged in the chatsession is displayed to each participant, with the participant thenhaving the ability to delete one or more messages in the chat sessionprior to saving/persisting. Each participant may form a correspondingedited text with healthcare system 150 then forming a new text based onedited text received from the different participants of the chatsession.

Healthcare system 150 stores the edited text in a non-volatile storagesuch as the data store noted above. The stored edited text representsthe chat history and may be later retrieved during future chat sessionscreated in relation to the patient.

Thus, various healthcare providers (and additional personnel) arefacilitated to effectively collaborate with each other in relation to apatient. It may be appreciated that the above interactions may beperformed multiple times by the physician or other participants as partof the chat session. In addition, the participants typicallysend/receive messages during the chat session as part of a discussionabout the patient based on the context information of the patientdisplayed as part of the chat session.

Referring to FIG. 1B, healthcare provider 120 sends a request (forexample, using a client system) to initiate a chat in relation to apatient. The request to initiate the chat may be sent in response toreceiving (via data link 112) a request from patient 110 forcheck-up/review with the healthcare provider. In alternativeembodiments, the chat request may be sent in response to receivingcorresponding requests for reviewing the condition of patient 110 frominsurance carrier 130 (via data link 132) or from enterprise 140 (viadata link 142).

Healthcare provider 120 then participates in a chat session with otherhealthcare providers as participants, the other healthcare providershaving responsibility for the patient. Healthcare provider 120 sends acommand as a text of the chat session, with the command requestinginformation on the patient. In response to the command, an electronicmedical record (EMR) of the patient is sent to the participants of thechat session. In one embodiment, healthcare provider 120 (using a clientsystem) does not specify the identifier of the patient as part of thecommand. In another embodiment, healthcare provider 120 shares the EMRof the patient without authentication after specifying the command.

Referring to FIG. 1C, insurance carrier 130 (a third-party differentfrom the first party healthcare system 150 and the second partyhealthcare provider 120) receives a request (from healthcare system 150via data link 135) for healthcare providers associated with a patient toinitiate a chat in relation to the patient, identifies healthcareproviders having responsibility for the patient, and sends theidentified healthcare providers as being associated with the patient tofacilitate a chat session to be provided with the healthcare providersas participants. Insurance carrier 130 may notify patient 110 and/orenterprise 140 (via data links 113 and 143 respectively) of the one ormore requests received from healthcare system 150.

Upon receiving another request requesting information on the patient inresponse to a command as a text of the chat session, insurance carrier130 retrieves an electronic medical record (EMR) of the patient andsends the EMR in response to receiving of another request to facilitatethe EMR to be provided to the participants of the chat session. In oneembodiment, the command is received from a first participant and doesnot specify the identifier of the patient in the chat session. Inanother embodiment, the EMR of the patient is retrieved withoutrequiring the first participant to manually authenticate afterspecifying the command.

Thus, the various entities/elements shown in FIGS. 1A-1C such as patient110, healthcare provider 120, insurance carrier 130, enterprise 140 andhealthcare system 150 are facilitated to effectively collaborate witheach other in relation to a patient. The manner in which severalfeatures of the present disclosure can be implemented using a computingsystem (system architecture) is described below with examples.

2. System Architecture

FIG. 2 is a block diagram of an example computing system in whichseveral aspects of providing effective collaboration in healthcaresystems can be implemented. The block diagram is shown containing clientsystems 210A-210Z, Internet 220, Intranet 240, external servers230A-230B, data stores 235A-235B & 270, application servers 260A-260B,healthcare server 250 and integration system 280.

In one embodiment, healthcare server 250, application servers 260A-260B,and data store 270 along with intranet 240 operate together to ashealthcare system 150 (as indicated by the dashed rectangle) thatprovides effective collaboration among various healthcare providers suchas physicians/doctors, medical staff/nurse, care providers, etc.

Each of systems 290A (containing external server 230A and data store235A) and 290B (containing external server 230B and data store 235B)represents a corresponding third-party external system with whichhealthcare system 150 interacts with to provide various aspects of thepresent disclosure. For example, external system 290A may represent asystem provided by insurance carrier 130, with external server 230Abeing an insurance server belonging to insurance carrier 130. Theinsurance server may maintain (in data store 235A) information onpatients having insurance coverage with insurance carrier 130. Externalsystem 290B may represent a system provided by enterprise 140, withexternal server 230B being an enterprise server belonging to enterprise140.

Merely for illustration, only representative number/type ofsystems/devices are shown in the Figure. Many environments often containmany more systems and/or devices, both in number and type, depending onthe purpose for which the environment is designed. Each system/device ofFIG. 2 is described below in further detail.

Each of client systems 210A-210Z represents a system such as a personalcomputer, workstation, mobile station, mobile phones, computing tablets,etc., used by users/healthcare providers to send user requests toapplications executing in healthcare system 150 (such as in applicationservers 260A-260B or healthcare server 250), and display thecorresponding responses. The responses may be in the form of web pagesand thus the requests may be in the form of Uniform Resource Locators(URLs) with appropriate additional content to specify the user requests.The users may generate the user requests based on appropriate userinterfaces provided on each client system. In one embodiment, clientsystems 210A-210Z runs on different operating systems such as ANDROID™and IOS™, and provide user interfaces using different web browserapplications such as INTERNET EXPLORER®, SAFARI™, FIREFOX® and CHROME®.

Intranet 240 represents a network providing connectivity betweenapplication servers 260A-260B, healthcare server 250 and data store 270,all provided as part of healthcare system 150. Internet 220 extends theconnectivity of these (and other systems of the healthcare system) withexternal systems such as client systems 210A-210Z and external systems290A-290B. Each of intranet 240 and Internet 220 may be implementedusing protocols such as Transmission Control Protocol (TCP) and/orInternet Protocol (IP), well known in the relevant arts. In general, inTCP/IP environments, an IP packet is used as a basic unit of transport,with the source address being set to the IP address assigned to thesource system from which the packet originates and the destinationaddress set to the IP address of the destination system to which thepacket is to be eventually delivered.

A (IP) packet is said to be directed to a destination system when thedestination IP address of the packet is set to the (IP) address of thedestination system, such that the packet is eventually delivered to thedestination system by Internet 220 and intranet 240. When the packetcontains content such as port numbers, which specifies the destinationapplication, the packet may be said to be directed to such applicationas well. The destination system may be required to keep thecorresponding port numbers available/open, and process the packets withthe corresponding destination ports. Each of Internet 220 and intranet240 may be implemented using any combination of wire-based or wirelessmediums.

Each of data stores 235A-235B and 270 represents a non-volatile(persistent) storage facilitating storage and retrieval of a collectionof data by applications executing in corresponding server systems. Forexample, data store 270 facilitates applications executing inapplications servers 260A-260B and healthcare server 250 tostore/retrieve data related to patients, healthcare providers, thehealthcare system, etc.

In one embodiment, each of data stores 235A-235B and 270 maintainsinformation on patients in the form of EMRs. As noted above, EMRs mayspecify details of patients including patient identity, dates of visit,symptoms of medical problem faced by the patient, lab reports, patientrecords, etc. Each data store may also store the conversations of theparticipants of chat/interactive sessions between the various healthcareproviders, the clinical data of the patients, etc.

Some of data stores 235A-235B and 270 may be implemented as a databaseserver using relational database technologies and accordingly providestorage and retrieval of data using structured queries such as SQL(Structured Query Language). Some of data stores 235A-235B and 270 maybe implemented as a file server providing storage and retrieval of datain the form of files organized as one or more directories, as is wellknown in the relevant arts.

Each of application servers 260A-260B, external servers 230A-230B andhealthcare server 250 represents a server system, such as aweb/application server, executing applications performing tasksrequested by users (for example, using one of client systems 210A-210Z).Each server system may use data stored internally (for example, in anon-volatile storage/hard disk within the server system), external data(e.g., maintained in data store 235A-235B/270) and/or data received fromexternal sources (e.g., from the user) in performing the requestedtasks. The server system then sends the result of performance of thetasks to the requesting client system (e.g., one of 210A-210Z). Theresults may be accompanied by specific user interfaces (e.g., web pages)for displaying the results to the requesting user.

Integration system 280 represents a server system that facilitateshealthcare server 250 to interact with external systems 290A-290B.Integration system 280 may accordingly provide integration APIs(Application Programming Interface) containing a library ofinterfaces/protocols to external systems, an integration database forstoring information sent/received from external systems, and a webserver that facilitates interaction with external systems that operatewith text based protocols such as Hyper Text Transfer Protocol Secure(HTTPS) and WebSocket Secure (WSS).

In one embodiment, one or more healthcare providers (e.g. physicians)using client systems 210A-210Z are facilitated to take part in a chatsession. Each healthcare provider is also facilitated to retrieve theinformation (EMR) related to a patient. However to share such patientinformation, a healthcare provider is required to manually enter (usingappropriate user interfaces) the patient information as one or more(chat) messages and send the messages to the other participants duringthe chat session. It may be appreciated that such manual entry may notbe desirable, for example, when the patient context information islarge.

Healthcare server 250, provided according to several aspects of thepresent disclosure, facilitates effective collaboration among healthcareproviders while overcoming some of the drawbacks noted above. The mannerin which healthcare server 250 (and accordingly healthcare system 150)provides effective collaboration is described below with examples.

3. General Flow

FIG. 3 is a flowchart illustrating the manner in which effectivecollaboration is provided in a healthcare system (150) according to anaspect of the present disclosure. The flowchart is described withrespect to healthcare server 250 of FIG. 2 merely for illustration.However, the features can be implemented in other systems andenvironments also without departing from the scope and spirit of variousaspects of the present disclosure, as will be apparent to one skilled inthe relevant arts by reading the disclosure provided herein.

In addition, some of the steps may be performed in a different sequencethan that depicted below, as suited to the specific environment, as willbe apparent to one skilled in the relevant arts. Many of suchimplementations are contemplated to be covered by several aspects of thepresent disclosure. The flow chart begins in step 301, in which controlimmediately passes to step 310.

In step 310, healthcare server 250 receives a request to initiate a chatin relation to a patient. The request may be received from one of clientsystems 210A-210Z by a user/healthcare provider such as aphysician/doctor. The request may be received when the physician wantsto review the status of his patients or in response to a patient comingfor check-up/review with the physician, either in-house or as anout-patient as is well known.

In one embodiment, healthcare server 250 enables the user/physician tospecify the details of the current visit of the patient, for example,based on the physical inspection/testing of the patient. During thevisit, the user/physician decides to collaborate with other healthcareproviders, for example, to discuss possible diagnosis and/or treatmentof the patient, and accordingly initiates the chat session. In thefollowing description, it is assumed that the user/physician is usingclient system 210A to send the request to initiate the chat.

In one embodiment, healthcare server 250 checks for validity ofauthentication details of the user/physician connecting via clientsystem 210A. If authentication details of the user are found invalid, anauthentication failed error message is displayed to the user. Inaddition, healthcare server 250 may allow the user to retry logging infor a predetermined number of times (which may be pre-configured).Control passes to step 320 if the authentication details of the user arefound valid.

In step 320, healthcare server 250 identifies healthcare providershaving responsibility for the patient. The identification may beperformed by examining the data stored in data store 270 and/orinterfacing with external servers 230A-230B. For example, a visitsummary data may be examined to determine the specific set of healthcareproviders that had interacted with the patient during the previousvisits.

In step 330, healthcare server 250 provides a chat/collaboration sessionwith the identified healthcare providers (previously visited/consultedby the patient) as participants of the chat session. A participant ofthe chat session implies that the healthcare provider is facilitated tosend and receive from/view messages with the other participants in thechat session. The chat session facilitates the user/physician to discusson the condition/medication of the patient (currently visiting theuser/physician) with the other healthcare providers.

In one embodiment, each of the identified healthcare providers is sentan invitation to join the chat session created in relation to thepatient. Upon the invited healthcare providers accepting the invite, theaccepting healthcare providers are added as participants to the chatsession. In the following description, it is assumed that the acceptinghealthcare providers are using a corresponding one of client systems210B-210Z to participate in the chat session.

In step 340, healthcare server 250 receives a command during the chatsession, the command requesting information on the patient. The commandmay be specified in any convenient manner, for example, as a stringforming part of text, by selection of a suitable user interface element,as a voice command, etc.

In one embodiment, healthcare server 250 facilitates the user/physicianto use custom commands to retrieve patient context information. A customcommand represents a pre-defined string of characters that is understoodby healthcare server 250 as indicating a corresponding action. Customcommands can be defined to have any convenient syntax. In an exampleimplementation, “&Patient” is used as the custom command to retrieve thepatient information. It may be readily observed that the custom command“&Patient” does not contain the identity details of the patient such asname of the patient, identity number of the patient, etc. andaccordingly does not require the participants to remember the identitydetails of the patients.

In another embodiment, the messages (and correspondingly the command)sent during the chat session are voice messages/command . For example ,instead of typing & Patient for retrieving patient data, a physician maysay “Get Patient Details” as voice command, with healthcare server 250in response identifying that a command requesting information on thepatient has been specified as part of the chat session.

In step 350, healthcare server 250 retrieves an EMR of the patient inresponse to the custom command “&Patient”. The EMR may be retrieved fromdata store 270 or from data stores 235A-235B by interfacing withexternal servers 230A-230B respectively. Multiple EMRs from thedifferent data stores may also be retrieved, with healthcare server 250then forming a consolidated EMR of the patient from the retrieved data.Such consolidation may involve operations such as validation, datamining and formatting on the data retrieved. The formatting may beaccording to the requirements of the client system sending the request(for example, based on whether client system 210A is a mobile device ora desktop computer), based on the preferences of the participants, etc.

In step 360, healthcare server 250 provides the EMR of the patient tothe participants of the chat session as a response to the command(“&Patient”). For example, healthcare server 250 may send the EMR of thepatient in a format ready for display on one or more of client systems210A-210Z. Each client system then presents/displays the patient contextinformation (EMR) as part of the chat session, such that all theparticipants of the chat session are able to view the patient contextinformation. In one embodiment, the information is displayed only for apre-configured time period (e.g. 10 seconds).

According to an aspect of the present disclosure, the patient contextinformation is provided in the form of one or more messages of the chatsession (similar to the other message manually sent by theparticipants). By providing as messages, the patient context messagesare facilitated to be saved/stored as part of chat history.

Thus, various healthcare providers are facilitated to effectivelycollaborate with each other in relation to a patient, while relieving aparticipant/healthcare provider from the burden of manual entry ofpatient information. It may be appreciated that the steps of 340, 350and 360 may be performed multiple times by the user/physician or otherparticipants as part of the chat session. In addition, the participantstypically send/receive messages during the chat session as part of adiscussion about the patient based on the context information of thepatient displayed in step 360.

In step 370, healthcare server 250 receives an indication tosave/persist the chat session. The indication may be received from anyone of the participants of the chat session using one of client systems210A-210Z. Saving the chat session implies that the text of the chatsession including the messages/files exchanged between the participants,the patient context information retrieved and displayed as part of thetext of the chat session, etc. be stored in a non-volatile storage suchas data store 270.

In step 380, healthcare server 250 enables the participants to edit thetext of the chat session to form an edited text. In one embodiment, thelist of messages exchanged in the chat session is displayed to aparticipant, with the participant then having the ability to delete oneor more messages in the chat session prior to saving/persisting. Eachparticipant may form a corresponding edited text with healthcare server250 then forming a new text based on edited text received from thedifferent participants of the chat session.

In step 390, healthcare server 250 stores the edited text in anon-volatile storage such as data store 270. The stored edited textrepresents the chat history and may be later retrieved during futurechat sessions created in relation to the patient. Control then passes tostep 399 where the flowchart ends.

It may be appreciated that steps 330 through 360 operate to facilitatethe participants in a chat session to access data/files on the externalEMR databases without requiring the participants to sign into theexternal EMR/EHR databases, use custom commands (that do not requireparticipants to remember patients' details) for retrieving data/filesfrom chat history and external EMR/EHR databases based on the context.Thus, healthcare server 250 (healthcare system 150) aids in providingeffective collaboration.

It may be further appreciated that the healthcare system 150 may providethe above described features to client systems 210A-210Z in anyconvenient manner. The description is continued illustrating the mannerin which aspects of the present disclosure are implemented in an examplegraphical user interface of a collaboration session in an embodiment.

4. Sample User Interfaces

FIG. 4 illustrates an example graphical user interface (GUI) of achat/collaboration session among multiple healthcare providers in anembodiment. A GUI entails aspects such as receiving of inputs from usersfor the application and displaying the outputs generated by theapplication, as is well known in the relevant arts. Furthermore, it maybe appreciated that GUIs may be customized based on various factors (forexample, based on whether the requesting client system is a mobiledevice or a desktop computer, based on the preferences of theparticipants, based on the branding guidelines of the customer/owner ofthe healthcare system, etc.).

Display area 400 represents a portion of a user interface displayed on adisplay unit (not shown) associated with one of client systems (assumedto be 210A, for illustration). In one embodiment, display area 400corresponds to a web page rendered by a browser executing on the clientsystem. Web pages are provided by healthcare server 250 in response to auser sending appropriate requests (for example, by specifyingcorresponding URLs in the address bar) using the browser.

For illustration, the description is continued assuming that displayarea 400 is being displayed on a system used by a healthcareprovider/physician (who initiated the collaboration). It should be notedthat user interfaces similar to display area 400 may be provided on allthe client systems/devices used by the other participants of the chatsession.

Display area 410 indicates the number of participants (“2”) in thecurrent chat session. Display area 420 indicates the number of availabledoctors/healthcare providers (“2”) who could be added as participants inthe chat session. Button 425 facilitates the user/physician to view andadd new participants (doctors) to the current chat session from a listof doctors. Button 430 facilitates the user/physician to save a copy ofthe chat session (including messages 460, 470, 480) according to aspectsof the present disclosure.

Display area 440 indicates the previous conversations of theuser/physician in particular with the care team. Display area 440 mayalso contain relevant documents/files pertaining to the patient. Aparticipant of the chat session may be allowed to review the pastconversations and documents/files to understand the status of thepatient better.

Display area 450 indicates a summary of the patient in respect of whomthe current chat session has been initiated. Display area 450 is shownindicating the name of the patient to be “Feinstein, Clara”. Each ofdisplay areas 460, 470 and 480 represents a corresponding message sentas part of the chat session. Display area 460 depicts the usage ofcustom command (&Patient) by one of the participants in the current chatsession (Joan Ames) to retrieve the patient's details. The retrievedpatient's details are shown in display area 470. Upon reviewingretrieved patient's details, chat may be continued with otherparticipants as shown in display area 480.

As may be readily appreciated from display areas 460 and 470, aparticipant can retrieve the information of a patient without having thenecessity to enter details such as patient's ID etc. In addition, thepatient related information is shown in display area 470 as part of thetext of the chat session, thereby enabling the EMR of the patient to bestored as part of the text of the chat session in a non-volatilestorage, if required (upon the user selecting button 430).

It may be appreciated that the above features of the present disclosuremay be provided by healthcare server 250 based on data maintained indata stores 235A-235B/270. Sample data that may be maintained in suchdata stores is described below with examples.

5. Sample Data

FIG. 5 depicts portions of a visit summary data specifying the detailsof interactions between patients and healthcare providers in oneembodiment. For illustration, the visit summary data are assumed to bemaintained in the form of tables in data store 270. However, inalternative embodiments, the visit summary data may be maintainedaccording to other data formats (such as files according to extensiblemarkup language (XML), etc.) and/or using other data structures (such aslists, trees, etc.), as will be apparent to one skilled in the relevantarts by reading the disclosure herein.

Table 500 depicts visit summary data specifying the details of visits ofdifferent patients to the healthcare organization. In particular, column511 “Patient ID” specifies a unique identifier associated with a patientand column 512 “Patient Name” specifies the name of the patient. Columns513 “HCP ID” and 514 “HCP Name” respectively specify a unique identifierand the name of the healthcare provider who attended to (and provided acorresponding healthcare service) to the patient. Column 515 “VisitDate/Time” specifies the date and time of the visit of the patient, andcolumn 516 “Details” specifies the details of the visit of the patient.Only a sample number of columns is shown in table 500, though inalternative embodiments, a large number of additional columns may bepresent to indicate additional details of the visit of the patient.

Each of rows 541-547 specifies the details of a corresponding visit bypatients. It may be readily observed that rows 542, 544 and 546 specifythe details of the visits by the patient having identifier “PT4125”(name “Feinstein, Clara”). Similarly, other rows specify the details ofvisits of other patients.

In response to receiving a request to initiate a chat in relation to apatient (assumed to be “PT4125” named “Feinstein, Clara” forillustration), healthcare server 250 inspects the visit summary data oftable 500 and identifies healthcare providers having responsibility forthe patient, that is, the healthcare providers who have treated thepatient during earlier visits. As such, healthcare server 250 identifiesthe healthcare providers “HP052”, “HP020” and “HP049” in rows 542, 544and 546 as having responsibility for the patient “PT4125”. It may beobserved that the healthcare provider “Joan Ames” identified in row 546is the user who sends the request to initiate the chat. Healthcareserver 250 then provides a chat session with the identified healthcareproviders “HP052”, “HP020” and “HP049” as participants.

Upon receiving a command (requesting information on the patient) as atext of the chat session, healthcare server 250 first determines thatthe current chat session has been created for patient “PT4125” andaccordingly sends the unique identifier to external systems (290A-290B)as the basis for retrieving an electronic medical record (EMR) of thepatient.

Thus, healthcare system 150 facilitates effective collaboration amonghealthcare providers using the visit summary data of table 500. Themanner in which healthcare system 150 may be implemented is describedbelow with examples.

6. Example Implementation

FIG. 6 is a block diagram illustrating an example implementation of ahealthcare system (150). The example implementation is shown in the formof a functional architecture containing multiple functional blocksimplemented in various systems (such as healthcare server 250 and datastore 270) belonging to healthcare system (150).

Healthcare server 250 is shown containing EMR service 610, authenticateservice 620, chat service 640, chat search commands 650, context service660, BOT engine 670, data mining/formatting 680 and web socket 690,while data store 270 is shown containing database 615 and doctor/patientmapping 625. It may be appreciated that in alternative embodiments, thevarious blocks/components may be implemented on multiple servers/datastores (which then together form healthcare system 150) as will beapparent to one skilled in the relevant arts. Each of the blocks of thehealthcare system is described in detail below.

EMR service 610 facilitates accessing of data from external systems suchas 290A-290B. For example, EMR service 610 may interact with theexternal systems such as integration system 280 to request forauthentication/authorization tokens for accessing the external EMR/EHRdata. Such authentication tokens may be stored in database 615 and laterused when accessing the external EMR/EHR data.

Database 615 facilitates storing/retrieving of data by other blocks inthe healthcare system based on SQL queries. Some examples of data thatmay be maintained in database 615 include, but not limited to,authentication token from EMR service 610, authentication data of theusers/healthcare providers from authenticate service 620, doctor/patientmapping data 625, chat history of the participants from chat service 640and context data from context service 660.

Authenticate service 620 facilitates authentication and/or authorizationof the users/healthcare providers to avail the services of thehealthcare system of the present disclosure. Authenticate service 620may employ standard authentication and/or authorization techniques wellknown in the relevant art such as Active Directory, Single Sign On,Database and LDAP. Furthermore, security technologies known in therelevant art (such as SSL) may be used by authenticate service 620during authentication and/or authorization. Authenticate service 620 maymaintain user related data in database 615 for providing theauthentication and/or authorization service.

Doctor/patient mapping 625 represents a mapping (data) between patientsand doctors such as list of doctors consulted by a patient and/or listof patients treated by a doctor. An example of such a mapping is thevisit summary data shown in table 500 of FIG. 5 . The doctor/patientmapping 625 may be updated periodically (for example, based onperiodical examination of external EMR/EHR data). In addition, themapping data may be updated by physician/healthcare providers during thevisits by the patients.

Upon successful authentication and/or authorization of theuser/healthcare provider, authenticate service 620 determines a list ofpatients handled by the authenticated user based on the information indoctor/patient mapping data 625 (as described in detail above).Authenticate service 620 then sends for display (for example, by sendingthe details to requesting client system 210A) the corresponding list ofpatients, thereby allowing the healthcare provider to access theprofiles of his/her patients (including complete medical history,information related to last visit, appointments etc.).

Chat service 640 enables chat/collaboration among multiple participantsof the healthcare system. Choosing/selecting a chat option for aparticular patient enables an authenticated participant to discuss abouta patient with other participants. In an example implementation, uponchoosing the chat option, chat service 640 initiates a chat session bycreating a group with all the participants (healthcare providers) havingresponsibility for the patient. Chat service 640 may use doctor-patientmapping data 625 for initiating the chat session. In addition, chatservice 640 may store a chat history specifying the details of chatsperformed earlier in database 615. Chat service 640 also may identifyand forward search commands issued by the participants during a chatsession to chat search commands 650.

Chat search commands 650 enables the participants in a chat session toissue search commands for required information such as patientinformation, last vital information, patient/doctor visits, files etc.in chat history (stored in database 615) and/or external EMR/EHRdatabases and to receive/view the results of the search commands. Chatsearch commands 650 may accordingly interact with context service 660 toperform the desired searches indicated by the issued search commands,receive the results of the searches and provide the results ascorresponding responses to the issued search commands.

Context service 660 enables other blocks/components of healthcare systemto retrieve required data from database 615 and and/or external EMR/EHRdatabases based on a context. The context may be related to a specificpatient, a specific healthcare provider, and/or the specific background(e.g. triaging, chat, etc.) in which the context service has beenrequested. Context service 660 receives requests from chat searchcommands 650 or BOT engine 670 indicating the specific data to beretrieved. Context service 660 may then retrieve the specific datarequested from database 615 and/or external EMR/EHR databases(235A-235B) and forwards the retrieved data as corresponding responsesto the requests.

BOT engine 670 provides an execution environment for executingbots/automated programs that perform a pre-defined set of actions,possibly by interacting with other systems such as client systems210A-210Z. Some bots run automatically, while others only executecommands when they receive specific inputs. Examples of bots are webcrawlers, chat room bots etc. Some of the bots may also facilitatepredictive analytics using predictive algorithms. For example, in thefield of healthcare, a patient info bot may pull the completeinformation/data of a patient from a database (which can be EMR/EHR andmay act on the data to find some relevant/meaningful information andadvice a doctor with suggestions about the areas of treatment).

In one embodiment, a chat bot (executing in BOT engine 670) performspredictive analytics (using predictive algorithms) on chat/collaborationhistory, chat context and commands given by participants during achat/collaboration session, and render the results/suggestions to theparticipants. For example, when a participant sends a message (typicallyin the form of text) in a chat session indicating that a patient issuffering from high fever, headache, rash, muscle and joint pain, a chatbot may search for the symptoms in chat/collaboration history (relatedto all patients) and may thereafter arrive at the suggestion that thepatient might be suffering from dengue fever (diagnosis). The chat botmay also suggest possible medications for the diagnosis.

Data mining/formatting 680 provides both mining and formatting servicessuch as formatting/modifying the results of the predictive analytics ofbot engine 670 according to the requirements of client systems210A-210Z, and send the formatted output (e.g. in the form of a report)to the client systems via web socket 690, thereby enabling clientsystems 210A-210Z to render the formatted output to the participants.

In addition, data mining/formatting 680 may also inspect the datareceived from bot engine 670 and determine additionalinsights/suggestions using mining algorithms well known in the art. Forexample, data mining/formatting 680 may identify additional data to beincluded to the data received from bot engine 670.

Web socket 690, well-known in the relevant arts, is a computercommunications protocol, providing full-duplex communication channelsover a single TCP connection, and facilitates peer to peer andclient-server communication. Web socket 690 facilitates thecollaborative communication among the participants (here healthcareproviders). Also, web socket 690 facilitates data mining/formatting 680to send the results/suggestions received from bot engine 670 toparticipants using client systems 210A-210Z.

It may be appreciated that the various components of FIG. 6 facilitate ahealthcare system (150) to provide several aspects of the presentdisclosure. According to an aspect of the present disclosure, chatservice 640 provides an effective and seamless collaboration among theparticipants of a chat/collaboration session, by obviating the necessityof the participants signing into external EMR/EHR databases (third-partydatabases) for accessing the data/files stored on the external EMR/EHRdatabases during the chat/collaboration session. As noted above, EMRservice 610 generates authentication tokens for external EMR/EHRdatabases, and thereafter uses the tokens during the chat session toprovide access to data/files stored on the external EMR/EHR databases.

According to one more aspect of the present disclosure, chat searchcommands 650 facilitates participants of a collaboration session tosearch for data/files by issuing search commands that do not require theparticipants to remember the details of the patients such as name of thepatient, identity number of the patient, etc. According to anotheraspect of the present disclosure, chat search commands 650 in operationwith context service 660 provides retrieval of meaningful and relevantinformation (data/files) based on the context in which the searchcommands are used.

The manner in which the various components of healthcare server 250shown in FIG. 6 operate to provide effective collaboration amonghealthcare providers is described below with examples.

7. Sequence Diagram for Effective Collaboration

FIG. 7 is a sequence diagram illustrating the manner in which effectivecollaboration with context awareness is provided by a healthcare system(150) in one embodiment. The interactions are shown between web/mobileclient 701 (executing in client system 210A), healthcare server 250,integration system 280 and user management system 702. It may beappreciated that though user management system 702 is shown as aseparate system, the same may be implemented as a part of healthcareserver 250. The interactions are described in detail below.

At 705, healthcare server 250 sends a request to integration system 280,requesting an authentication token/key to access an external EMR/EHRdatabase (such as 290A-290B). Integration system 280 may then interactwith the external EMR/EHR database and obtain the authentication token.At 710, integration system 280 sends the authentication token tohealthcare server 250, using which healthcare server 250 is thereafterfacilitated to access the EMR/EHR data stored in the external EMR/EHRdatabase. Healthcare server 250 may store the authentication token indatabase 615 for subsequent usage.

At 715, web/mobile client 701 sends a user authentication request tohealthcare server 250 when a user/physician enters his/herauthentication details at web/mobile client 701. Healthcare server 250then forwards the user authentication request to user management system702. At 720, user management system 702 performs the validation of theauthentication details contained in the user authentication request, andsends the results of validation as a response to the user authenticationrequest to healthcare server 250, which in turn forwards the response toweb/mobile client 701. Upon the response indicating an error invalidation of the authentication details, web/mobile client 701 displaysan error message to the user/physician.

The description is continued assuming that the response indicatessuccessful validation of the user/physician. The user/physician maythereafter perform additional activities and then initiate a chatconversation/collaboration session with other physicians. Accordingly,the user/physician may be shown the user interface of FIG. 4 onweb/mobile client 701, and the user/physician may thereafter exchangemessages with the other participants of the chat/collaboration session.

At 725, web/mobile client 701 sends a patient info request to healthcareserver 250 when the user/physician specifying custom command “&Patient”in display area 460 of FIG. 4 . Healthcare server 250 then forwards thepatient info request to integration system 280, along with theauthentication token retrieved from database 615. Integration system 280interacts (using the authentication token) with the external EMR/EHRdatabase noted above to retrieve the requested patient information.

At 730, integration system 280 sends the retrieved patient informationas a response to the patient info request. Healthcare server 250receives the retrieved patient information from integration system 280and manipulates the received patient information (for example, to suitthe formatting requirements of web/mobile client 701) and sends themanipulated output to web/mobile client 701. Web/mobile client 701displays the manipulated output (formatted patient information) touser/physician as shown in display area 470 of FIG. 4 .

As noted above, the various participants in the chat session mayexchange messages using interfaces similar to FIG. 4 provided oncorresponding one of client systems 210A-210Z. The manner in which suchmessages are processed is described in detail below.

At 735, web/mobile client 701 forwards a message to healthcare server250 when the user/physician enters the message in the user interface ofFIG. 4 . At 740, healthcare server 250 receives the message fromweb/mobile client 701 and forwards the same to other client systems usedby the other participants of the chat session. In an embodiment, wheremultiple instances of healthcare server 250 are active (such as FIG. 8described below) or where the participants belong to multiple EMRsystems are connected to other application servers, healthcare server250 forwards the message received from web/mobile client 701 to theother healthcare servers, which in turn forwards the message to theclient systems used by participants. Furthermore, healthcare server 250receives messages from the other client systems and forwards themessages to web/mobile client 701, which then displays the messages inuser interface of FIG. 4 .

It may be appreciated that the above noted actions at 725 and 730 areperformed in view of the authentication token being valid andaccordingly being recognized by the external EMR/EHR database. However,such authentication token are often valid only for a fixed period andare considered expired after the fixed period. The manner in which anexpired authentication token is handled when processing a request forEMR/EHR data is described in detail below.

At 745, web/mobile client 701 sends a last vital info request tohealthcare server 250 when the user/physician specifies a correspondingcustom command (e.g. “&LastVital”). Healthcare server 250 then forwardslast vital info request to integration system 280, along with theauthentication token retrieved from database 615. Integration system 280interacts (using the authentication token) with the external EMR/EHRdatabase to determine that the authentication token has expired. At 750,integration system 280 accordingly sends a response to the last vitalinfo request indicating that the authentication token has expired. At755, healthcare server 250 sends a request for authentication token tointegration system 280 and in response, at 760, integration system 280sends a new authentication token to healthcare server 250. Actionsperformed at 755 and 760 are similar to the actions performed at 705 and710 and accordingly their description is not repeated here for the sakeof conciseness.

Upon receiving the new authentication token, at 765, healthcare server250 resends the request for last vital info along with the newauthentication token to integration server 290. At 770, integrationsystem 280 sends a response to healthcare server 250, which in turnforwards to web/mobile client 701 after performing suitablemanipulation. Actions performed at 765 and 770 are similar to theactions performed in 725 and 730 and the description is not repeatedhere for the sake of conciseness. Thus, the EMR/EHR data is providedaccess during the chat session even when the previously generatedauthentication token has expired.

It may be appreciated that the operation of FIGS. 2 through 7facilitates the healthcare system to provide effective collaborationamong the healthcare providers present in the healthcare system.

It may be further appreciated that the features of the presentdisclosure are described above assuming that the healthcare system isimplemented on a single server (healthcare server 250 of FIG. 2 ).However, healthcare systems are typically implemented using multipleservers and data stores. The manner in which a healthcare system may beprovided using a cloud infrastructure is described below with examples.

8. Healthcare System Using Cloud Infrastructure

FIG. 8 is a block diagram illustrating the manner in which a healthcaresystem is provided using a cloud infrastructure in an embodiment.Specifically, the healthcare system is shown implemented using AWS(Amazon Web Services) framework 800 available from Amazon[TM].Accordingly, the block diagram is shown containing SSL (Secure Socketslayer) 805, firewall 810, load balancer 815, Amazon Elastic ComputeCloud (Amazon EC2) 820, security layers 825, application server(instance) 850, and multi tenancy 840.

It should be appreciated that the healthcare system is implemented usingmultiple (typically, 50-100) application servers, though only a singleapplication server 850 is shown in FIG. 8 for clarity.

SSL 805 is a standard security technology for establishing an encryptedlink between application server 850 and any of client systems 210A-210Z.Firewall 810 is a network security device that monitors traffic to orfrom a network. Firewall 810 also allows or blocks traffic based on adefined set of security rules. Amazon EC2 820 is a web service thatprovides secure, resizable compute capacity on the cloud. ApplicationLoad Balancer (ALB) 815 distributes the user requests among the variousapplication servers for reasons such as scalability, fault tolerance,etc. Security layers 825 provide additional level of security for thehealthcare system in addition to SSL 805 and firewall 810. Multi tenancy840 handles the tenancy of healthcare system in Amazon EC2 820.

Application server 850 is shown containing core services 830 andadapters/plugins 835 (in addition to associated components such as websocket, micro services and bot engine described above with respect toFIG. 6 ). Core services 830 facilitate the interaction among one or moreapplication servers and also the interaction with client systems210A-210Z, while adapters/plugins 835 facilitate application server tointeract with external systems (via integration system 280). Some ofcore services 830 and adapters/plugins 835 are described in detailbelow.

Messaging service enables messages to be sent among application serversand/or client systems 210A-210Z. Such messages may be encrypted usinguser keys. Signaling service is used to provide audio/video calls forcollaboration among participants on client systems 210A-210Z. Suchaudio/video calls may be provided using WebRTC, WebSocket and Amazon EC2820. Push mechanism pushes messages such as alerts or emergencynotifications to the client system used by the appropriate user (heredoctor/nursing staff). Multiple sessions service enables a user to logininto multiple client systems simultaneously. Email service enables auser to compose and send emails including any attachments if any.

Backup/appointment service enables user to assign another user as backup (in cases of emergency) on his/her unavailability. In addition,backup appointment service sends alerts or emergency notifications toanother user assigned as back up. Furthermore, backup/appointmentservice enables recording of appointments for patient's consultations.As an example, recording of appointments includes modifying date, timeand doctor mapped for consultation.

EMS (Enterprise Messaging Service) service provides multi factorauthentications for users. For example, a two factor authentication (twolevels of verification) of login details of a user may be provided.Details of such two levels of verification are sent via emails, SMS(Short Messaging Service), etc. Admin service enables a user to fetchdata from PHI (Protected Health Information) systems via integrationsystem 280. File transfer service enables a user to send/share documentsto another user in real time, for example, during collaboration. Inaddition, file transfer service may encrypt the documents beforesending/sharing.

Offline notification service sends alerts to a user notifying emergencywhen client systems 210A-210Z are in offline mode. Offline notificationservice uses Firebase/APNs (Apple Push Notification Service) to send thealerts, for example, in the form of alarm beeps. Chat service enableschat based collaboration among multiple participants including sendingof private messages, creating chat rooms/groups and storing the chathistory.

EMR/EHR adapter enables retrieving of EMR of patients from externalEMR/EHR systems via integration system 280. Exemplary data in EMRincludes patient documents, medications, patient info, care plan, doctornotes, observations, clinical summary and visits details. CRM adapterfacilitates data to be retrieved from an external CRM system viaintegration system 280. Google service adapter facilitates applicationserver 850 to interface with Google [TM] services. Advisor serviceadapter facilitates interactions with third party bots to retrievesuggestions and recommendations. IAM (Identity and Access Management)adapter facilitates interactions with external servers to performauthentication and/or authorization of the users/healthcare providers inthe healthcare system.

IoT service adapter facilitates interactions with IoT devices such asheart monitors. Such interaction may facilitate application server 850to determine whether heart beat of a patient monitored through an IoTdevice records a lower value or a higher value than the standardthresholds, and then send an alert to the appropriate medical staff(nurse/doctor).

Additional components such as Micro services, Web sockets and Bot enginemay be associated with application server 850. Micro services are backend services or self-sustained services built as per client's specificrequirements as needed. These can be any plug and play services. Forexample, in healthcare industry, the micro services render the patientdata required by the doctors. Web socket and Bot engine are describedabove with respect to FIG. 6 .

Communication database 845 represents a non-volatile (persistent)storage facilitating storage and retrieval of data by applicationsexecuting in other systems such as application server 850. Communicationdatabase 845 may be implemented as a database server using relationaldatabase technologies and accordingly provide storage and retrieval ofdata using structured queries such as SQL (Structured Query Language).Alternatively, or in addition, communication database 845 may beimplemented as a file server providing storage and retrieval of data inthe form of files organized as one or more directories, as is well knownin the relevant arts.

It should be appreciated that the features described above can beimplemented in various embodiments as a desired combination of one ormore of hardware, executable modules, and firmware. The description iscontinued with respect to an embodiment in which various features areoperative when executable modules are executed.

9. Digital Processing System

FIG. 9 is a block diagram illustrating the details of digital processingsystem 900 in which various aspects of the present disclosure areoperative by execution of appropriate executable modules. Digitalprocessing system 900 corresponds to healthcare server 250 orapplication server 850.

Digital processing system 900 may contain one or more processors such asa central processing unit (CPU) 910, random access memory (RAM) 920,secondary memory 930, graphics controller 960, display unit 970, networkinterface 980, and input interface 990. All the components exceptdisplay unit 970 may communicate with each other over communication path950, which may contain several buses as is well known in the relevantarts. The components of FIG. 9 are described below in further detail.

CPU 910 may execute instructions stored in RAM 920 to provide severalfeatures of the present disclosure. CPU 910 may contain multipleprocessing units, with each processing unit potentially being designedfor a specific task. Alternatively, CPU 910 may contain only a singlegeneral-purpose processing unit.

RAM 920 may receive instructions from secondary memory 930 usingcommunication path 950. RAM 920 is shown currently containing softwareinstructions constituting shared environment 925 and user programs 926.Shared environment 925 includes operating systems, device drivers,virtual machines, etc., which provide a (common) run time environmentfor execution of user programs 926.

Graphics controller 960 generates display signals (e.g., in RGB format)to display unit 970 based on data/instructions received from CPU 910.Display unit 970 contains a display screen to display the images definedby the display signals (e.g. portions of the GUI shown in FIG. 4 ).Input interface 990 may correspond to a keyboard and a pointing device(e.g., touch-pad, mouse) that may be used to provide appropriate inputs(e.g. inputs specified in the user interfaces of FIG. 4 ). Networkinterface 980 provides connectivity to a network (e.g., using InternetProtocol), and may be used to communicate with other systems (of FIG. 1) connected to the network.

Secondary memory 930 may contain hard drive 935, flash memory 936, andremovable storage drive 937. Secondary memory 930 may store the data(for example, portions of visit summary data of FIG. 5 ) and softwareinstructions (for implementing the flowchart of FIG. 3 and to provideseveral features of the present disclosure), which enable digitalprocessing system 900 to provide several features in accordance with thepresent disclosure. The code/instructions stored in secondary memory 930either may be copied to RAM 920 prior to execution by CPU 910 for higherexecution speeds, or may be directly executed by CPU 910.

Some or all of the data and instructions may be provided on removablestorage unit 940, and the data and instructions may be read and providedby removable storage drive 937 to CPU 910. Removable storage unit 940may be implemented using medium and storage format compatible withremovable storage drive 937 such that removable storage drive 937 canread the data and instructions. Thus, removable storage unit 940includes a computer readable (storage) medium having stored thereincomputer software and/or data. However, the computer (or machine, ingeneral) readable medium can be in other forms (e.g., non-removable,random access, etc.).

In this document, the term “computer program product” is used togenerally refer to removable storage unit 940 or hard disk installed inhard drive 935. These computer program products are means for providingsoftware to digital processing system 900. CPU 910 may retrieve thesoftware instructions, and execute the instructions to provide variousfeatures of the present disclosure described above.

The term “storage media/medium” as used herein refers to anynon-transitory media that store data and/or instructions that cause amachine to operate in a specific fashion. Such storage media maycomprise non-volatile media and/or volatile media. Non-volatile mediaincludes, for example, optical disks, magnetic disks, or solid-statedrives, such as secondary memory 930. Volatile media includes dynamicmemory, such as RAM 920. Common forms of storage media include, forexample, a floppy disk, a flexible disk, hard disk, solid-state drive,magnetic tape, or any other magnetic data storage medium, a CD-ROM, anyother optical data storage medium, any physical medium with patterns ofholes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memorychip or cartridge.

Storage media is distinct from but may be used in conjunction withtransmission media. Transmission media participates in transferringinformation between storage media. For example, transmission mediaincludes coaxial cables, copper wire and fiber optics, including thewires that comprise bus 950. Transmission media can also take the formof acoustic or light waves, such as those generated during radio-waveand infra-red data communications.

Reference throughout this specification to “one embodiment”, “anembodiment”, or similar language means that a particular feature,structure, or characteristic described in connection with the embodimentis included in at least one embodiment of the present disclosure. Thus,appearances of the phrases “in one embodiment”, “in an embodiment” andsimilar language throughout this specification may, but do notnecessarily, all refer to the same embodiment.

Furthermore, the described features, structures, or characteristics ofthe disclosure may be combined in any suitable manner in one or moreembodiments. In the above description, numerous specific details areprovided such as examples of programming, software modules, userselections, network transactions, database queries, database structures,hardware modules, hardware circuits, hardware chips, etc., to provide athorough understanding of embodiments of the disclosure.

10. Conclusion

While various embodiments of the present disclosure have been describedabove, it should be understood that they have been presented by way ofexample only, and not limitation. Thus, the breadth and scope of thepresent disclosure should not be limited by any of the above-describedexemplary embodiments, but should be defined only in accordance with thefollowing claims and their equivalents.

It should be understood that the figures and/or screen shots illustratedin the attachments highlighting the functionality and advantages of thepresent disclosure are presented for example purposes only. The presentdisclosure is sufficiently flexible and configurable, such that it maybe utilized in ways other than that shown in the accompanying figures.

Further, the purpose of the following Abstract is to enable the PatentOffice and the public generally, and especially the scientists,engineers and practitioners in the art who are not familiar with patentor legal terms or phraseology, to determine quickly from a cursoryinspection the nature and essence of the technical disclosure of theapplication. The Abstract is not intended to be limiting as to the scopeof the present disclosure in any way.

What is claimed is:
 1. A method comprising: receiving, via a healthcaresystem, a command during a chat session, the command requestinginformation on a patient along with a first authentication token;forwarding the command requesting information on the patient to anintegration system; automatically determining, via the integrationsystem, that the first authentication token is valid and requesting fora second authentication token when the first authentication token isexpired; retrieving, in response to receiving of the command via thehealthcare system, an electronic medical record, EMR, of the patientwhen one of the first authentication token and the second authenticationtoken is valid; and sending, via the healthcare system, the electronicmedical record to participants of the chat session in the response toreceiving of the command in real time and when one of the firstauthentication token and the second authentication token is valid; andwherein the healthcare system is configured to facilitate collaborationamong healthcare providers via the healthcare system.
 2. The method ofclaim 1, further comprises: forming, via the healthcare system, a visitsummary by mapping doctor with patient, wherein doctor to patientmapping is updated automatically based on examination of data fromexternal electronic medical record system; receiving, via the healthcaresystem, a request to initiate the chat session in relation to thepatient; identifying, via the healthcare system, a plurality ofhealthcare providers having responsibility for the patient from thevisit summary; and providing, via the healthcare system, the chatsession with the plurality of healthcare providers as the participantsusing corresponding client system.
 3. The method of claim 2, wherein themethod is configured to form a consolidated electronic medical record ofthe patient from retrieved data of the electronic medical record.
 4. Themethod of claim 3, further comprises performing predictive analyticsusing predictive algorithms on at least one of a chat, a collaborationhistory, a chat context, commands given by the participants during thechat session, and the consolidated electronic medical record of thepatient to render treatment suggestions and insights to theparticipants.
 5. The method of claim 4, wherein performing thepredictive analytics using the predictive algorithms further comprises:searching for symptoms in at least one of the chat, and thecollaboration history; and arriving at the treatment suggestions andinsights regarding at least one of a diagnosis and medications for thediagnosis, based on a message by the participants in the chat session.6. The method of claim 2, wherein the chat session is automaticallyintegrated with identity number of the patient.
 7. The method of claim2, wherein the command need not specify an identifier of the patient inthe chat session.
 8. The method of claim 2, wherein the externalelectronic medical record system maintains the electronic medical recordof the patient, the command being received from a first participant, themethod further comprising retrieving, via the healthcare system, theelectronic medical record of the patient from the external electronicmedical record system without requiring the first participant tomanually authenticate after specifying the command.
 9. The method ofclaim 5, wherein the sending, via the healthcare system, comprisesincluding the electronic medical record of the patient as the message ofthe chat session; and wherein the electronic medical record of thepatient is enabled to be stored as part of a chat history of the chatsession in a non-volatile storage.
 10. The method of claim 5, furthercomprising: receiving, via the healthcare system, an indication to savethe chat session; enabling, via the healthcare system, the participantsto edit the message of the chat session to form an edited text; andstoring, via the healthcare system, the edited text in a non-volatilestorage.
 11. A tangible non-transitory machine-readable mediumcomprising instructions executable by one or more processors forimplementing one or more operations in a healthcare system forfacilitating collaboration among healthcare providers, the operationscomprising: receiving, via the healthcare system, a command during achat session, the command requesting information on a patient along witha first authentication token, retrieving information; forwarding thecommand requesting information on the patient to an integration system;automatically determining, via the integration system, that the firstauthentication token is valid and requesting for a second authenticationtoken when the first authentication token is expired; retrieving, inresponse to receiving of the command via the healthcare system, anelectronic medical record, EMR, of the patient when one of the firstauthentication token and the second authentication token is valid;sending, via the healthcare system, the electronic medical record toparticipants of the chat session in the response to receiving of thecommand in real time and when one of the first authentication token andthe second authentication token is valid; and wherein the healthcaresystem is configured to form a consolidated electronic medical record ofthe patient from retrieved data of the electronic medical record. 12.The tangible non-transitory machine-readable medium of claim 11, furthercomprises instructions to perform operations comprising: forming, viathe healthcare system, a visit summary by mapping doctor with patient,wherein doctor to patient mapping is updated automatically based onexamination of data from external electronic medical record system;receiving, via the healthcare system, a request to initiate the chatsession in relation to the patient; identifying, via the healthcaresystem, a plurality of healthcare providers having responsibility forthe patient from the visit summary; and providing, via the healthcaresystem, the chat session with the plurality of healthcare providers asthe participants using corresponding client system.
 13. The tangiblenon-transitory machine-readable medium of claim 12, wherein the externalelectronic medical record system maintains the electronic medical recordof the patient, the command being received from a first participant, theoperations further comprising retrieving, via the healthcare system, theelectronic medical record of the patient from the external electronicmedical record system without requiring the first participant tomanually authenticate after specifying the command.
 14. The tangiblenon-transitory machine-readable medium of claim 12, wherein the sendingcomprises including, via the healthcare system, the electronic medicalrecord of the patient as a message of the chat session; and wherein theelectronic medical record of the patient is enabled to be stored as partof a chat history of the chat session in a non-volatile storage.
 15. Thetangible non-transitory machine-readable medium of claim 12, furthercomprises instructions to perform operations comprising performingpredictive analytics using predictive algorithms on at least one of achat, a collaboration history, a chat context, commands given by theparticipants during the chat session, and the consolidated electronicmedical record of the patient to render treatment suggestions andinsights to the participants.
 16. A digital processing systemcomprising: a memory to store instructions; one or more processors toexecute the instructions stored in the memory to cause the digitalprocessing system to perform actions of: receiving, via a healthcaresystem, a command during a chat session, the command requestinginformation on a patient along with a first authentication token,retrieving information; forwarding the command requesting information onthe patient to an integration system; automatically determining, via theintegration system, that the first authentication token is valid andrequesting for a second authentication token when the firstauthentication token is expired; retrieving, in response to receiving ofthe command via the healthcare system, an electronic medical record,EMR, of the patient when one of the first authentication token and thesecond authentication token is valid; sending, via the healthcaresystem, the electronic medical record to participants of the chatsession in the response to receiving of the command in real time andwhen one of the first authentication token and the second authenticationtoken is valid; and wherein the healthcare system is configured to forma consolidated electronic medical record of the patient from retrieveddata of the electronic medical record.
 17. The digital processing systemof claim 16, wherein the command is received from a first participantand does not specify an identifier of the patient in the chat session,wherein the electronic medical record is retrieved without requiring thefirst participant to manually authenticate after specifying the command.18. The digital processing system of claim 16, wherein the electronicmedical record of the patient is displayed as part of the chat sessionfor a pre-configured time period.
 19. The digital processing system ofclaim 16, wherein the digital processing system is an insurance serverbelonging to an insurance carrier, the insurance server maintaininginformation on patients having insurance coverage with the insurancecarrier.
 20. The digital processing system of claim 16, wherein thedigital processing system is an enterprise server belonging to athird-party enterprise.